---

Introduction

I program for fun, not for profit. When I can produce a program that seems good enough to share with others--a "releasable program"--it gives me a pretty nice rush. I thought that I would share some of the things that I do which help me develop programs to a releasable state. (Click here for a list of links to small applications and demos written by Nally.)

Before I do that, however, let me offer this concession: for the hobbyist programmer, the process of programming is very valuable "brain work" even if the programmer isn't able to nuture her project to a releasable state. Just the act of programming provides good exercise for your mind. So, even if you've never produced a program that you were willing to share with others, don't give up on the activity of programming. I think it's good for you. Certainly, not all of my projects have evolved to a releasable state.

Defining Programming Success For the Hobbyist

I usually have pretty modest goals for my programming projects. I don't labor under the expectation that my program has to be the next Microsoft Excel, which I happen to think is the greatest productivity application ever written.

Rather, when I develop a program, I'm hoping that I can offer the user perhaps 20 or 30 minutes of stimulation over several consecutive days. If I'm able to do that, I consider it a victory. If I can pique the user's curiosity sufficiently to cause him to take a look at the code, even better! Since I program for cerebral treasure rather than material treasure, my reward comes during development.

In summary, when I've derived 10-30 hours of stimulation during development, followed by 30 minutes to an hour of stimulation for my users, that's a win-win situation. I consider the results a "good program".

Some might argue that these objectives are insufficiently ambitious. Perhaps so, but this is a leisure-time activity for me, and having modest goals has allowed me to move through projects rather quickly, while remaining pretty excited about each one.

With success modestly defined, here are my tips for hobby programming.

Tip #1: A project with a narrow scope has a higher chance of becoming "releasable".

I begin programming projects with the expectation that the programming effort will come to a successful conclusion within 2-4 weeks, and will result in a releasable application. For me, if the scope of a programming project appears so large that the effort would need several months of work, it is unlikely that I would start that project (though there have been exceptions). The reason is this: in several months time, I know that I can become distracted by other activities, which would leave the project unfinished.

My experience is that productive programming occurs when the programmer gets into a "rhythm"; develops a certain amount of programming "momentum"; and finds herself "in the zone". For me, a project that would require three months of work would cause me to lose rhythm, lose momentum, and fall out of the zone.

Here's an example. I wrote a fireworks simulator in Liberty BASIC called BoomSim. I knew that fireworks are essentially rockets, and possess the attribute known as "thrust". Yet, I knew that if I had to learn the physics of thrust, doing so would add more time and an extra level of complication to the project, and would make finishing the project less likely. So, I limited the scope by making my fireworks particles behave like balls thrown into the air, a model whose mathematics I already understood. The results were pretty good, and BoomSim took a little less than a week to produce.

Of course, if you finish your project earlier than expected, or with less effort than expected, then there is nothing wrong with increasing the scope by extending the application, or adding features or nuances.

Tip #2: Use "Freeform", or Alyce Watson's Liberty BASIC Workshop to create the interface.

Using one of the two products identified above makes creation of your user interface extremely easy. The most ambitious application that I've done to date, Humble CAD, was laid out with Freeform. With the exception of that, every other releasable application that I've built was constructed with Liberty BASIC Workshop (LBW).

In fact, I have relied on LBW so thoroughly that I am unable to recite the syntax for creation of any of the standard Windows controls. LBW's GUI Builder creates the syntax for you after you have placed all the controls you need onto your form. If Freeform and LBW weren't available to relieve the tedium of form creation "by hand", I expect that I would not have been as productive.

Tip #3: Write your programs with Liberty BASIC Help available in the background.

I follow this guideline consistently. Having Liberty BASIC Help already open makes for programming productivity by providing instant access to all the commands and keywords.

But I just don't read the documentation. Rather, I frequently copy-and-paste the syntax (or the examples) from the help files straight into my project. Then, I merely change the words where appropriate, creating bug-free statements.

Tip #4: There are occasions when "clear" code is better than "efficient" code.

Like many other crafts, programming often provides opportunities to combine a sequence of steps into a single step. There are occasions when I resist this opportunity, especially if it will make my code more difficult to understand one week or one month hence.

Applying this guideline has proven helpful to me when I've done programming which has been math-intensive. For example, during the development of the Collision Simulator, I was testing a mathematical formula that was 80 (+/-) characters long. I made the formula this long by combining multiple mathematical operations into a single formula. I was motiviated to do this because I knew that computing ball paths after collisions would take thousands of iterations, and I wanted the process to be speedy.

But during testing, all I could get was aberrant ball behavior. I got to the point where I decided that I would only spend another 30 minutes on the project. If I couldn't get the process to work correctly after that time, I would abandon the Collision Simulator. I thought that there was only a very small chance that I could get the application to work.

I finally decided that I would dissemble the long lines of code into shorter lines of code, even if it would result in a slower-executing application. In other words, I was deliberately making the code less efficient, with the hope of establishing order and clarity. This process corrected some logical fault in the formulas, and the Collision Simulator became a releasable application.

Tip #5: Consider using Microsoft Excel for graphics development.

Okay, I doubt that many readers will buy into this one, but Excel has been a great asset supporting my programming efforts. Whenever I need a splash screen or a background, I will always start with Excel's built-in Graphics tools. Excel graphics has dozens of basic geometric shapes, and supports grouping, ungrouping, stretching, scaling, rotating, flipping, mirroring and re-ordering. Additionally, Excel has "Word Art", which allows you to create stylized titles and headings.

One unappreciated graphic capability of Excel is that it offers practically unlimited drawing space! Often, I might draw three or four versions of the same graphic, placing them adjacent to each other in the same worksheet. This allows me to easily compare them before deciding which one should go into the Liberty BASIC application.

One might ask how the programmer migrates his Excel graphic object into his Liberty BASIC program. I merely keep Windows Paint open in the background. Then I copy the Excel graphic by using Control-C, then paste it into Paint by using Control-V. With the graphic residing in Paint, I save it as a bitmap.

Tip #6: Provide a help document with your application, even if it is a minimal one.

Earlier in this article I mentioned that I have two objectives as a hobby programmer. One is to enjoy a measure of stimulation during development of the program. The second objective is to provide my users with a half-hour of amusement or so. Providing a help document may not help accomplish the first objective, but it can help accomplish the second.

A help document should explain what the program does, and what the user must do to operate the program. If the program has hidden nuances which could make the program more interesting to the user, then the developer should discuss those.

I also believe that managing the user's expectations can be helpful in developing the user's appreciation for your programming effort. For this reason, it might be good for your help document to discuss the program's limitations.

I've used many different technologies to produce help documents. When I want to produce extensive, standard Windows help, I use Helpblocks, which is a commercial application with a $50 registration fee.

But there are other ways to produce help files which require less effort. In Humble CAD Viewer, which was released as part of Newsletter 115, all my help documents were text files, accessible via Notepad opened from the Humble CAD Viewer menu. Another simple way to provide small doses of help is to use Liberty BASIC's NOTICE dialog box, as shown in the graphic on the right.

Epilogue: What happens when you can't develop your application to a releasable state?

Knowing what can't be done in a limited time frame can be just as valuable as knowing what can be done. When it happns to me, I typically spend about 20 seconds in abject disappointment...before wondering about the next cool programming project just over the horizon!

Seriously, in the land of bits and processors, there are too many awesome programming adventures to be experienced for the hobby programmer to worry about the application that couldn't be developed in the hobbyist's limited leisure time.

Go get 'em!